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1 REMARKS 

2 These remarks follow the order of the paragraphs of the office action. Relevant portions of the 

3 office action are shown indented and italicized. 
4 

5 DETAILED ACTION 
6 

7 This action is responsive to the Amendment/Arguments filed on January 14,2008. Claims 

8 1-25 are pending. 
9 

10 Response to Arguments 
11 

12 1. Applicant's arguments with respect to Claim Objections under 37 CFR 1.75(c) have 

13 been hilly considered and are persuasive. The objections to Claims 5, 9, 17, and 23 have 

14 been with drawn. 
15 

16 2. Applicant's arguments with respect to Claim Objections due to minor informalities 

17 have been fully considered and are persuasive. The objections to Claims 6, 7, 8, 12, 17,. 

18 18, 20, and 25 have been withdrawn 
19 

20 3. Applicant's arguments with respect to Claim Rejections under 35 U.S.C. 112, second 

21 paragraph, have been fully considered and are persuasive. The rejections of Claims 2.3, 

22 and 21 have been withdrawn. 
23 

24 4. Applicant's arguments with respect to Claim Rejections under 35 U.S.C. 102 have 

25 been hilly considered but they are not persuasive. 
26 

27 a. "Thus, Osborn is directed to a hardware resource identifier (19) recognizes hardware 

28 resource dependencies in a multi-channel communications system. Osborn is concerned 

29 with assigning labels to system hardware resources to identify relationships, between the 
30 

31 system hardware resources and external hardware, to discern redundant resources 

32 within respective ones of the hardware resource groups, and to characterize dedicated 

33 coupling between individual ones of the system hardware resources. This is not related to 

34 the present invention as claimed in Claims 1-6. 9-14, 19. and 21-25. " 
35 

36 The Applicant 's citation of Osborn 's abstract without any arguments regarding the 

37 claimed invention is insufficient to show how the claims patentably distinguish from the 

38 cited prior art. 

39 Furthermore, Osborn' s disclosure has multiple embodiments in addition to those 

40 shown in the abstract that, as shown below, disclose the limitations of Claims 1-6, 9-14, 

41 19, and 21 -25. 
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1 b. "Osborn is apparently not concerned with provisioning and managing computing 

2 services in a computing utility system by generating a Concrete Model that describes a 

3 resource structure that refines the input and is implementable over the infrastructure. " 
4 

5 Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a 

6 general allegation that the claims define a patentable invention without specifically 
1 pointing out how the language of the claims patentably distinguishes them from the 
8 references. 

9 

10 Furthermore, as rejected below, Osborn discloses generating an application abstract 

1 1 resource description describing a resource structure that is derived from the object 

12 specification mentioned above and is mapped to resources in the system. 
13 

14 c. "Osborn is also not concerned with generating and executing provisioning actions to 

15 create an identical resource structure on the infrastructure. " 
16 

17 Applicant's arguments fall to comply with 37 CFR 1.111(b) because they amount to a 

18 general allegation that the claims define a patentable invention without specifically 

19 pointing out how the language of the claims patentably distinguishes them from the 

20 references. 
21 

22 Furthermore, as rejected below, Osborn discloses obtaining an abstract resourec 

23 description describing virtual hardware resource objects and using the abstract resource 

24 description to create a matching resource structure to satisfy the requirements of the 

25 service environment. 

26 d. "But, these 'object specification, or application specification, with virtual application 

27 objects of an application which describe requirements associated with the application, ' 

28 apparently have no relation to claim 1 elements. Some words and phrases may be similar 

29 to words and phrases in claim 1. but are not related to the steps of claim I. A review of 

30 Osborn fails to show Osborn teaching alleged in the office communication. For example, 

31 the cited Osborn portion column 3 lines 17-44 reads: ' 
32 

33 The object specification, or application specification, anticipates the Service 

34 Environment Model as claimed. Furthermore, Applicant cited a different portion of 

35 Osborn than was cited in the rejection. 
36 

37 c. "Applicants respectfully states that a review of the above fails to indicate concern 

38 with, anticipation or teaching of: 
39 

40 any model; any Concrete Model: any computing utility; any computing utility 

41 infrastructure; any service; any service requirements; any desire of satisfying a set of 

42 service requirements; any Service Environment Model; any service environment; 
43 
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1 any step of generating to obtain a Service Environment Model of a service environment; 

2 any description of a new desired state of any service environment; 
3 

A any Infrastructure Model; 
5 

6 any Infrastructure Model describing resources and an organization of the resources; any 

1 computing utility infrastructure; 

8 

9 any knowledge subsystem; 
10 

1 1 any Infrastructure Model encapsulated in a knowledge subsystem; any step of generating 

12 a Concrete Model; 
13 

14 any Concrete Model that describes a structure of resources implementable over a 
15 

16 computing utility infrastructure, and satisfying a set of service requirements, said step of 

17 generating comprising the steps of: " Applicant's arguments fail to comply with 37 (FR 

18 1.111(b) because they amount to a general allegation that the claims define a patentable 

19 invention without specifically pointing out how the language of the claims patentably 

20 distinguishes them from the references. Simply citing portions from the references does 

21 not constitute an adequate argument. 
22 

23 Furthermore, as rejected below, Osborn discloses obtaining an object specification, or 

24 application specification, which anticipates the Service Environment Model as claimed. 

25 obtaining a hardware abstract resource description, or hardware specification, 

26 describing resources and an organization of the resources which anticipates the 

27 Infrastructure Model as claimed, and generating an application abstract resource 

28 description describing a resource structure which anticipates generating a Concrete 

29 Model as claimed. 
30 

31 / "Applicants respectfully states that a review of the above fails to show any Osborn 

32 concern with, anticipation or teaching of: 
33 

34 forming any Concrete Model; 
35 

36 any Concrete Model describing a resource structure; any Concrete Model that refines 

37 any Service Environment Model; any Concrete Model that is mappable; 
38 

39 any Concrete Model that is mappable to any knowledge subsystem; or 
40 

41 any step of forming a Concrete Model describing, a resource structure such that the 

42 Concrete Model refines the Service Environment Modal and is mappable to said 

43 knowledge subsystem. 
AA 
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1 Applicant's arguments fall to comply with 37 CFR 1.111(b) because they amount to a 

2 general allegation that the claims define a patentable invention without specifically 

3 pointing out how the language of the claims patentable distinguishes them from the 

4 references. Simply citing portions from the references does not constitute an adequate 

5 argument. 
6 

7 Furthermore, as rejected below, Osborn discloses generating an application abstract 

8 resource description describing a resource structure that is derived, from the object 

9 specification and is mappable to resources in the system. This anticipates the Concrete 
10 Model as claimed. 

11 

12 g. "This doesn't teach claim 2 elements. Thus claim 2 is allowable for itself and because 

13 it depends on an allowable claim. " 
14 

15 Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a 

16 general allegation that the claims define a patentable invention without specifically 

17 pointing out how the language of the claims patentable distinguishes them from the 

18 references. Simply citing portions from the references does not constitute an adequate 

19 argument. 

20 Furthermore, as rejected below, Osborn discloses the object specification, or application 

21 specification, includes virtual application objects that describe requirements on a new 

22 desired state of the service environment of the application. 
23 

24 In addition, in view of the aforementioned argument that Osborn discloses each and 

25 every limitation of Claim 1, Applicant's argument that Claim 2 depends on an allowable 

26 claim is moot. 



27 In response, the applicants respectfully states that the response is specific and indeed not general 

28 allegation. The response cites the references portion of the cited art, and clearly points out the 

29 deficiency of the citation to support the alleged teaching. Applicants show that the claims define 

30 a patentable invention and does specifically pointing out how the language of the claims 

31 patentably distinguishes them from the references. Simply citing portions from the references 

32 does not constitute an adequate argument. When a reference fails to teach what it is alleged to be 

33 teaching, one can not say where in the citation the teaching is not. The teaching is not anywhere. 
34 

35 Applicants point out and list the particular elements of the claims that are clearly not taught by 

36 the reference. 

37 Furthermore, as rejected below, Osborn discloses the object specification, or application 

38 specification, includes virtual application objects that describe requirements on a new 

39 desired state of the service environment of the application. 
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1 

2 In addition, in view of the aforementioned argument that Osborn discloses each and 

3 every limitation of Claim 1, Applicant's argument that Claim 2 depends on an allowable 

4 claim is moot. 
5 

6 h. "In response, the applicants respectfully states that this doesn't teach claim 3 

1 elements. 

8 Thus clam 3 is allowable for itself and because it depends on an allowable claim. " 
9 

10 Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a 

1 1 general allegation that the claims define a patentable invention without specifically 

12 pointing out how the language of the claims patentably distinguishes them from the 

13 references. Simply citing portions from the references does not constitute an adequate 

14 argument. 
15 

16 Furthermore, as rejected below, Osborn discloses the object specification, or application 

17 specification, that does not depend on the computing utility infrastructure. 
18 

19 In addition, in view of the aforementioned argument that Osborn discloses each and 

20 every limitation of Claim 1, Applicant's argument that Claim 3 depends on an allowable 

21 claim is moot. 

22 In response, the applicants respectfully states that the response is specific and indeed not general 

23 allegation. A clear showing was made of what Osborn fails to teach. As stated previously 

24 Osborn fails to disclose Claim 1 or any of the presently claimed inventions. 

25 5. Applicant's arguments with respect to Claim Rejections under 35 U.S.C. 103 have 

26 been fully considered but they are not persuasive. 

27 i. "So, there is no reason to make this combination except in an attempt to find a 

28 combination that allegedly has the elements of these claims to make the claims obvious. 

29 This is hindsight which is not allowed. But, even the combination does not teach the 

30 combined elements. 
31 

32 Applicant fails to make any argument to justify this conclusion. It is insufficient to merely 

33 insert a section of the cited reference. 
34 

35 Furthermore, in response to applicant's argument that the examiner's conclusion of 

36 obviousness is. based upon improper hindsight reasoning, it must be recognized that any 

37 judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight 

38 reasoning. But so long as it takes into account only knowledge which was within the level 

39 of ordinary skill at the time the claimed invention was made, and does not include 

40 knowledge gleaned only from the applicants disclosure, such a reconstruction is proper. 
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1 Sec In re McLaughlin, 443 F.2d 1392,. 1 70 USPQ 2Q9 (CCPA 1971 ). 

2 

3 j. 'In response, the applicants, respectfully states that the various combinations of art 

4 fail to make any of the. claims obvious, since they all are combined with Osborn which 

5 Fails to teach even the independent claims. 
6 

7 In view of the aforementioned argument that Osborn discloses each and every limitation 

8 of Claims 1 and 21, Applicant's argument is moot. 

9 In response, the applicants respectfully states that the response is specific and clearly shows the 

10 lack of an obviousness showing. A showing was made of what Osborn fails to teach claims 1 

11 and 21, and the so called combined art reconstruction does not support a 103 rejection. As stated 

12 previously Osborn even as combined fails to disclose or make obvious any of the presently 

13 claimed inventions, with or without 

14 Claim Rejections -35 USC § 102 
15 

16 6. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form 

17 the basis for the rejections under this section made in this Office action: 
18 

19 A person shall be entitled to a patent unless - 

20 (e) the invention was described in(l) an application for patent, published under section 

21 122(b), by another filed in the United States before the invention by the applicant for 

22 patent or (2) a patent granted on an application for patent by another filed in the United 

23 States before the invention by the applicant for patent, except that an international 

24 application filed under the treaty: defined in section 351(a) shall have the effects for 

25 purposes of this sub-subsection of an application filed in the United States only if the 

26 international application designated the United States and was published under Article 

27 21(2) of such treaty in the English language. 
28 

29 

30 7. Claims 1-6, 9-14, 19, and 21-25 are rejected under 35 U.S.C. 102(e) as being 

31 anticipated by (US. Patent No. 7,050,807 fded on June 12, 2000 by Osborm (denoted 

32 herein as "Osborn"). 

33 In response, the applicant respectfully states that Claims 1-6, 9-14, 19, and 21-25 are not 

34 anticipated by the invention of Osborn. The present invention, claimed in Claims 1-6, 9-14, 19, 

35 and 21 -25 provides for: 
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1 "provisioning and managing computing services in a computing utility system. It receives 

2 as an input an infrastructure independent description of a set of requirements on the new 

3 desired state of a computing service. It uses a knowledge plane to represent the 

4 infrastructure. The method generates a Concrete Model that describes a resource structure 

5 that refines the input and is implementable over the infrastructure. It then generates and 

6 possibly executes provisioning actions to create an identical resource structure on the 

7 infrastructure. The method can be used to create new computing services, to destroy 

8 existing computing services, to modify the resource combinations allocated to a 

9 computing service, or the configuration of these resources. Provisioning actions can be 

10 executed immediately, or saved and executed later, and possibly many times. 

1 1 Provisioning actions may be regenerated using the method whenever infrastructure 

12 characteristics, or the service requirements change." 



13 Thus, the present invention in Claims 1-6, 9-14, 19, and 21-25 are directed to provisioning and 

14 managing computing services in a computing utility system by generating a Concrete Model that 

15 describes a resource structure that refines the input and is implementable over the infrastructure. 

16 It also is concerned with generating and executing provisioning actions to create an identical 

17 resource structure on the infrastructure. 

18 It is noted, that the manageability model for Web services endpoint is defined as concrete models 

19 in UML using the topics and aspects concepts, without implying any particular implementation 

20 or locus of implementation. Appropriate manageability interfaces are defined based on the UML 

21 manageability models. The Unified Modelling Language (UML) is an Object Management 

22 Group (OMG) standard for modelling software artifacts. 

23 Whereas, the cited art to Osborn , US Patent 7,050,807, filed: June 12, 2000, is entitled: 



24 "Hardware resource identifier for software-defined communications system". The Osborn 

25 abstract reads: 

26 "A hardware resource identifier (19) recognizes hardware resource dependencies in a 

27 multi-channel communications system. Initially, system communications domains 

28 (D1-D4) in which system hardware resources are located are identified. Next, managed 
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1 hardware resources, hardware resource groups and hardware resource group boundaries 

2 among the system hardware resources are identified. Association labels are then assigned 

3 to the system hardware resources to identify relationships, if any, between the system 

4 hardware resources and external hardware, to discern redundant resources within 

5 respective ones of the hardware resource groups, and to characterize dedicated coupling 

6 between individual ones of the system hardware resources. An abstract resource 

7 specification (78) is then interpreted to locate available system hardware resources, as 

8 organized into the system identified communications domains and the identified hardware 

9 resource groups, to enable maximum preservation of most functional and least available 
10 hardware resources during hardware resource allocation". 



1 1 Thus, Osborn is directed to a hardware resource identifier (19) recognizes hardware resource 

12 dependencies in a multi-channel communications system. Osborn is concerned with assigning 

13 labels to system hardware resources to identify relationships, between the system hardware 

14 resources and external hardware, to discern redundant resources within respective ones of the 

15 hardware resource groups, and to characterize dedicated coupling between individual ones of the 

16 system hardware resources. This is not related to the present invention as claimed in Claims 1-6, 

17 9-14, 19, and 21-25. 



18 Osborn is apparently not concerned with provisioning and managing computing services in a 

19 computing utility system by generating a Concrete Model that describes a resource structure that 

20 refines the input and is implementable over the infrastructure. Osborn is also not concerned with 

21 generating and executing provisioning actions to create an identical resource structure on the 

22 infrastructure. Thus, Claims 1-6, 9-14, 19, and 21-25 are allowable over Osborn. 

23 8. As for claims 1 and 21, Osborm discloses a method comprising (an apparatus 

24 comprising means for) generating a Concrete Model, said Concrete Model describing a. 

25 structure of resources implementable over a computing utility infrastructure, and 

26 satisfying a set of service requirements, said step of generating comprising the steps of: 
27 

28 (means for) obtaining a Service Environment Model of a service environment, said 

29 Service Environment Model describing a set of requirements on a new desired state of 

30 said service environment ( Osborn discloses obtaining an object specification, or 

31 application specification. 
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1 with virtual application objects of an application which describe requirements 

2 associated with the application, see column 3 lines 44-59, column 4 lines 15-23, and 

3 Figure 2 reference number 68); (means for) getting an Infrastructure Model describing 

4 both resources and an organization of the resources in the computing utility 

5 infrastructure, said Infrastructure Model is encapsulated in a knowledge subsystem 

6 ( Osborn discloses obtaining a hardware abstract resource description, or 

1 hardware specification, in a system describing both resources and an organization of 

8 the resources, tee column 3 lines 17-44 and Figure 8); and 

9 

10 (means for) forming the Concrete Model describing a resource structure such that said 

1 1 Concrete Model refines the Service Environment Model and is mappable to said 

12 knowledge subsystem ( Osborn discloses generating an application abstract resource 

13 description describing a resource structure, see Figure 9, that is derived from the object 

14 specification mentioned above and is mapped to resources in the system, see column 3 

15 lines 60-67 and column 4 lines 1-14). 

16 In response, the applicants respectfully states that exception is taken with the alleged teaching of 

17 the elements of claim 1 by Osborn. Claim 1 reads: 

18 1. A method comprising generating a Concrete Model, said Concrete Model describing a 

19 structure of resources imp lemen table over a computing utility infrastructure, and 

20 satisfying a set of service requirements, said step of generating comprising the steps of: 

21 obtaining a Service Environment Model of a service environment, said Service 

22 Environment Model describing a set of requirements on a new desired state of said 

23 service environment; 

24 getting an Infrastructure Model describing both resources and an organization of the 

25 resources in the computing utility infrastructure, said Infrastructure Model is encapsulated 

26 in a knowledge subsystem; and 

27 forming the Concrete Model describing a resource structure such that said Concrete 

28 Model refines the Service Environment Model and is mappable to said knowledge 

29 subsystem . 
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1 Exception is taken with the alleged teaching of Osborn as stated above, in the following: 

2 ( Osborn discloses obtaining an object specification, or application specification, with 

3 virtual application objects of an application which describe requirements associated with 

4 the application, see column 3 lines 44-59, column 4 lines 15-23, and Figure 2 reference 

5 number 68); 

6 Maybe. But, these "object specification, or application specification, with virtual application 

7 objects of an application which describe requirements associated with the application," 

8 apparently have no relation to claim 1 elements. Some words and phrases may be similar to 

9 words and phrases in claim 1, but are not related to the steps of claim 1 . A review of Osborn 

10 fails to show Osborn teaching alleged in the office communication 

1 1 For example, the cited Osborn portion column 3 lines 17-44 reads: 

12 The hardware resource manager 18 is responsible for allocating hardware resources to 

13 system applications so that the least available and most functional of the available 

14 hardware resources 14 are not allocated until all options for using more available and/or 

15 less functional hardware resources for an application are exhausted. Details as to how the 

16 hardware resource manager 18 allocates hardware resources are given in co-pending 

17 application Ser. No. 09/586,120 entitled Dynamic Hardware Resource Manager For 

18 Software-Defined Communications System, assigned to Motorola Corporation and 

19 incorporated herein by reference. The hardware resource manager 18 allocates hardware 

20 resources to an application based on characteristics, or attributes, of available hardware 

21 resource such as, for example, resource capabilities, name, type, flavor, shared, version, 

22 and address characteristics stored in a hardware specification maintained on the system 

23 platform 12 and updated as hardware resources are added or removed, as well as on 

24 configuration characteristics tracked and generated by a hardware resource identifier 19. 

25 The hardware resource identifier 19 of the present invention then uses this characteristic 

26 hardware resource information to generate a hardware specification, graphically 

27 illustrated as an abstract resource specification (78 in FIG. 2), that identifies hardware 

28 resource constraints and interdependencies and that is used by the hardware resource 

29 manager 18 to designate certain of the resources 14 as allocated resources 15. 
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1 Applicants respectfully states that a review of the above fails to indicate concern with, 

2 anticipation or teaching of: 

3 any model; 

4 any Concrete Model; 

5 any computing utility; 

6 any computing utility infrastructure; 

7 any service; 

8 any service requirements 

9 any desire of satisfying a set of service requirements 

10 any Service Environment Model; 

1 1 any service environment; 

12 any step of generating to obtain a Service Environment Model of a service environment; 

13 any description of a new desired state of any service environment; 

14 any Infrastructure Model 

15 any Infrastructure Model describing resources and an organization of the resources; 

16 any computing utility infrastructure; 

17 any knowledge subsystem; 

18 any Infrastructure Model encapsulated in a knowledge subsystem; 

19 any step of generating a Concrete Model; 

20 any Concrete Model that describes a structure of resources implementable over a 

21 computing utility infrastructure, and satisfying a set of service requirements, said step of 

22 generating comprising the steps of: 

23 Exception is also taken with the alleged teaching of the elements of claim 1 by Osborn of: 

24 (means for) forming the Concrete Model describing a resource structure such that said 

25 Concrete Model refines the Service Environment Model and is mappable to said 

26 knowledge subsystem ( Osborn discloses generating an application abstract resource 

27 description describing a resource structure, see Figure 9, that is derived from the object 

28 specification mentioned above and is mapped to resources in the system, see column 3 

29 lines 60-67 and column 4 lines 1-14). 

30 The cited Osborn portion column 3 lines 60-67 reads: 
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1 From information provided in the application specification 34, the application manager 

2 16 also creates an abstract resource description 72 including virtual hardware resource 

3 objects 74 which identify application hardware requirements, and which are transmitted 

4 to the hardware resource manager 18 and mapped at 76 in the abstraction layer 54 to the 

5 available system hardware resources 14, based on the hardware resource interdependency 

6 data in the abstract resource specification 78 generated by the hardware resource 

7 identifier 19 of the present invention, to create the allocated hardware resources 15 (the 

8 object specification 68, the abstract resource description 72 and all other specifications 

9 necessary to define an application are subsets of the application specification 34). The 

10 objects 36 are then loaded onto the allocated hardware resources 15 through the 

1 1 abstraction layer 54 at 38 to run the requesting application. The hardware resource 

12 identifier 19 applies hardware resource constraints and interdependencies as represented 

13 generally by the arrows 76 in the static specification stage 60 by interpreting the abstract 

14 hardware resource description 72 to enable the available hardware resources 14 to be 

15 effectively allocated by the hardware resource manager of the present invention. 

16 The cited Osborn portion column 4 lines 1-14 reads: 

17 From information provided in the application specification 34, the application manager 

18 16 also creates an abstract resource description 72 including virtual hardware resource 

19 objects 74 which identify application hardware requirements, and which are transmitted 

20 to the hardware resource manager 18 and mapped at 76 in the abstraction layer 54 to the 

21 available system hardware resources 14, based on the hardware resource interdependency 

22 data in the abstract resource specification 78 generated by the hardware resource 

23 identifier 19 of the present invention, to create the allocated hardware resources 15 (the 

24 object specification 68, the abstract resource description 72 and all other specifications 

25 necessary to define an application are subsets of the application specification 34). The 

26 objects 36 are then loaded onto the allocated hardware resources 15 through the 

27 abstraction layer 54 at 38 to run the requesting application. The hardware resource 

28 identifier 19 applies hardware resource constraints and interdependencies as represented 

29 generally by the arrows 76 in the static specification stage 60 by interpreting the abstract 



DOCKET NUMBER: CH920010003US1 



19/44 



Serial No.: 10/776,297 



1 hardware resource description 72 to enable the available hardware resources 14 to be 

2 effectively allocated by the hardware resource manager of the present invention. 

3 Applicants respectfully states that a review of the above fails to show any Osborn concern with, 

4 anticipation or teaching of: 

5 forming any Concrete Model; 

6 any Concrete Model describing a resource structure; 

7 any Concrete Model that refines any Service Environment Model; 

8 any Concrete Model that is mappable; 

9 any Concrete Model that is mappable to any knowledge subsystem; or 

10 any step of forming a Concrete Model describing a resource structure such that the 

11 Concrete Model refines the Service Environment Model and is mappable to said 

12 knowledge subsystem . 



13 Thus claim 1 and all claims that depend on claim 1 are allowable over Osborn. 



14 In accordance with a suggestion by the Examiner and the Supervisor in a telephone conversation, 

15 in order to bring this application to allowance, applicants have amended claim 1 to better define 

16 the elements, and more specifically point out the novelty. It is anticipated that this amendment 

17 will result in the allowance of amended claim 1 and all claims that depend from it. 

18 9. As for claim 2, Osborn discloses each and every limitation of claim 1. Osborn further 

19 discloses wherein the step of obtaining a Service Environment Model of the service 

20 environment includes receiving a description of a set of requirements on a new desired 

21 state of said service environment ( Osborn discloses the object specification, or 

22 application specification, includes virtual application objects that describe requirements 

23 on a new desired state of the service environment of the application, see column 3 lines 

24 44-59, column 4 lines 15-23. and Figure 2 reference number 68). 



25 In response, the applicants respectfully states that exception is taken with the alleged teaching of 

26 the elements of claim 2 by Osborn. A review of all the cited portions of Osborn fails to support 
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1 the teaching of any of the claims 1-25 of this application. The cited portions are copied below to 

2 show that indeed the alleged teaching of the elements of each claim are apparently not in Osborn. 

3 Thus, all claims are allowable over Osborn, even when combined with the other references cited 

4 below, for obviousness purposes. 

5 The cited Osborn portion column 3 lines 44-59 reads: 

6 FIG. 2 is a more detailed block diagram of the topology of the system architecture of the 

7 multi-channel software-defined radio 10 shown in FIG. 1. As shown, the architecture 

8 includes several functional layers, including an application object layer 50, a virtual 

9 hardware layer 52, an abstraction layer 54 and a physical hardware layer 56, as well as 

10 several application management stages, including a static specification stage 60, a 

11 hardware allocation stage 62, an object creation stage 64 and an application startup stage 

12 66. The functional layers 50-56 operate to load the application objects 36 onto the 

13 allocated hardware resources 15 based on the application specification 34, as well as the 

14 composite hardware specification provided by the hardware resource identifier 19 based 

15 on its processing of the static system hardware specification 40 provided with the system 

16 as well as its processing of the dynamic hardware discovery results. 

17 The cited Osborn portion column 4 lines 15-23 reads: 

18 The application object layer 50 includes the virtual application objects 35, which are in an 

19 object specification 68 and which identify software application objects 36 necessary to 

20 run a system application. The application manager 16 retrieves the identified application 

21 objects 36 from the application object libraries 37 based on the virtual objects 35 in the 

22 object specification 68 and loads the objects 36 onto the allocated hardware resources 15 

23 as indicated at 38. 

24 This doesn't teach claim 2 elements. Thus clam 2 is allowable for itself and because it depends 

25 on an allowable claim. 
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1 Claim 2 is amended to overcome an antecedent problem, and is certainly allowable. 
2 

3 10. As for claim 3, O shorn discloses each and every limitation of claim 1. O shorn further 

4 discloses wherein said Service Environment Model description is independent of the 

5 computing utility infrastructure ( Osborn discloses the object specification, or application 

6 specification, that does not depend on to the computing utility infrastructure, see column 
1 3 lines 44-59, column 4 lines 15-23, and. Figure 2 reference number 68). 



8 In response, the applicants respectfully states that the cited Osborn portion column 3 lines 44-59 

9 reads as stated above. The cited Osborn portion column 4 lines 15-23 reads as stated above. 

10 Applicants respectfully states that this doesn't teach claim 3 elements. Thus clam 3 is allowable 

1 1 for itself and because it depends on an allowable claim. 
12 



13 11. As for claim 4, Osborn discloses each and every limitation of claim 1. Osborn further 
14 

15 discloses wherein said service environment is an entity taken from a group of entities 

16 consisting 
17 

18 of: 

19 a Web site, 

20 an on-line gaming service, 

21 a scientific computation service, 

22 an e-business service, 

23 a computing service ( Osborn discloses a service environment for an application, see 

24 column 3 lines 60-67 and column 4 lines 1-14), 

25 and any combination of these. 
26 

27 12. As for claim 5. Osborn discloses each and every limitation of claim 1. An article of 

28 manufacture comprising a computer usable medium having computer readable program 

29 code means embodied therein for causing generation of a Concrete Model, the computer 

30 readable program code means in said article of manufacture comprising computer 

31 readable program code means for causing a computer to effect the steps of claim 1 

32 ( Osborn discloses the system of Figures 1 and 2 to effect the steps of claim 1, sec Figures 

33 land 2). 

34 In response, the applicants respectfully states that 

35 

36 13. As for claim 6, Osborn, discloses each and every limitation of claim 1. Osborn 

37 further discloses wherein the step of getting an Infrastructure Model includes an action 

38 taken from a group of actions consisting of: 
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1 

2 querying at least one knowledge subsystem entity ( Osborn discloses obtaining the 

3 hardware abstract resource description by obtaining information from a hardware 

4 resource manager, see column 3 lines 28-43); 

5 The cited Osborn portion column 3 lines 28-43 reads: 

6 The hardware resource manager 18 is responsible for allocating hardware resources to 

7 system applications so that the least available and most functional of the available 

8 hardware resources 14 are not allocated until all options for using more available and/or 

9 less functional hardware resources for an application are exhausted. Details as to how the 

10 hardware resource manager 18 allocates hardware resources are given in co-pending 

1 1 application Ser. No. 09/586, 120 entitled Dynamic Hardware Resource Manager For 

12 Software-Defined Communications System, assigned to Motorola Corporation and 

13 incorporated herein by reference. The hardware resource manager 18 allocates hardware 

14 resources to an application based on characteristics, or attributes, of available hardware 

15 resource such as, for example, resource capabilities, name, type, flavor, shared, version, 

16 and address characteristics stored in a hardware specification maintained on the system 

17 platform 12 and updated as hardware resources are added or removed, as well as on 

18 configuration characteristics tracked and generated by a hardware resource identifier 19. 

19 The hardware resource identifier 19 of the present invention then uses this characteristic 

20 hardware resource information to generate a hardware specification, graphically 

21 illustrated as an abstract resource specification (78 in FIG. 2), that identifies hardware 

22 resource constraints and interdependencies and that is used by the hardware resource 

23 manager 18 to designate certain of the resources 14 as allocated resources 15. 

24 Office communication states: 

25 querying Resource Managers ( Osborn discloses obtaining the hardware abstract 

26 resource description by obtaining information from a hardware resource manager, see 

27 column 3 lines 28-43), 

28 The cited Osborn portion column 3 lines 28-43 reads as stated above. 
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1 



querying Resource Instance Services, 



2 



querying a best practices catalog; 



3 
4 
5 



obtaining knowledge of available resource types (Osborn discloses obtaining the 
hardware abstract resource description by obtaining information on resource group 
types, see column 5 lines 52-56 and Figure 8); 



6 The cited Osborn portion column 5 lines 52-56 reads: 

7 At 184, all resource group types and boundaries are identified. Specifically, any collection 

8 of highly coupled hardware resources is a good candidate to be identified as a resource 

9 group. Also, identical sets of hardware resources are identified as identical group types. 



10 obtaining knowledge of resources constraints ( Osborn discloses obtaining the hardware 

1 1 abstract resource description by obtaining information on resource group designations and 

12 other constraints inherently associated with resource attributes, see column 6 lines 3-20 and 

13 Figure 8); 

14 obtaining knowledge of resource capabilities ( Osborn discloses obtaining the hardware abstract 

15 resource description by obtaining information on resource attributes, see column 6 lines 45-65 

16 and Figure 8); 

17 The cited Osborn portion column 6 lines 45-65 reads: 

18 Next, at 188 the abstract resource diagram is generated to organize the available hardware 

19 resources into the above-discussed domains and resource groups. FIG. 8 shows an 

20 exemplary abstract representation 168 of a subset of managed device resource groups for 

21 the multi-channel radio shown in FIG. 5. Each device is characterized by a list of 

22 attributes and one or more assigned association labels assigned, although only certain of 

23 the attributes and association labels are shown for ease of illustration and explanation. For 

24 example, the attribute and association labels for the transmitter port 154c in the RF 

25 resource group 126 identifies the resource as a port type resource with an RS422 flavor at 

26 system address /qcScc/11 and with a "tx," or transmitter, association. Such information 
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1 



describes the hardware resources and their connectivity using an abstract resource 
notation. The information of the abstract resource diagram generated by the systems 
designer can be easily encoded into hardware resource specification files 40 to describe 
all of the managed hardware resources and underlying interdependencies to the hardware 



2 



3 



4 



5 



resource identifier 19. 



6 obtaining knowledge of infrastructure constraints (Osborn discloses obtaining the hardware 

1 abstract resource description by obtaining information on resource group designations and 

8 other constraints inherently associated with resource attributes, see column 6 lines 3-20 and 

9 Figure 8); 

10 The cited Osborn portion column 6 lines 3-20 reads: 

11 In order for the resource group designations to be useful to the hardware resource 

12 manager, the hardware resource identifier 19 must identify the managed devices within 

13 the resource groups. For example, the hardware resources within the dashed box in FIG. 7 

14 are identified by the hardware resource identifier as belonging to the RF resource group 

15 126. Therefore, if an application specification requests tightly coupled resources, they can 

16 all be allocated from the same RF resource group, such as the resource group 126. A 

17 signal may then be input through the receiver 144, pass through the modem 146 and then 

18 be transmitted through the external RF 138 by the transmitter 148. Alternatively, if the 

19 communication application could process the signal by requesting a super-circuit that 

20 required, for example both of the RF resource groups 126, 128, the signal could, for 

21 example, be input through the receiver 144 of RF resource group 126, pass through the 

22 modem 146, and then pass through the modem 158 and be transmitted by a transmitter 

23 175 of the RF resource group 128. 

24 obtaining knowledge of infrastructure capabilities ( Osborn discloses obtaining the hardware 

25 abstract resource description by obtaining information on resource attributes, see column 6 lines 

26 45-65 and Figure 8); 



DOCKET NUMBER: CH920010003US1 



25/44 



Serial No.: 10/776,297 



1 The cited Osborn portion column 6 lines 45-65 reads as stated above. 

2 obtaining knowledge of infrastructure best practices patterns; 

3 and any combination of these actions. 

4 These copied referenced portions fail to support the alleged teachings. 
5 

6 14. As for claim 9, Osborn discloses each and every limitation of claim 1. Osborn further 

1 discloses a program storage device readable by machine, tangibly embodying a program 

8 of instructions executable by the machine to perform method steps for generating a 

9 Concrete Model, said method steps comprising the steps of claim 1 ( Osborn discloses the 
10 system of Figures 1 and 2 that comprise the. steps of claim 1, see Figures 1 and 2). 

11 

12 15. As for claim 10, Osborn discloses each and every limitation of claim 1. Osborn 

13 further discloses further comprising using said generating said Concrete Model to 

14 enforce a policy based service provider's best practices in implementation of Service 

15 Environments in the computing utility infrastructure (Osborn discloses generating the 

16 Concrete Model to enforce the requirements needed to run the application, see column 3 

17 lines 1-8 and column 4 lines 15-23). 

18 The cited Osborn portion column 3 lines 1-8 reads: 

19 The application manager 16 is responsible for executing a system application, typically in 

20 response to an operator-initiated event, based on a stored application specification 34 that 

21 is associated with the application. The application specification 34 contains application 

22 object descriptions, known as virtual objects, 35 required hardware resource information 

23 and software object to hardware processor mapping information that application 

24 developers need to guarantee correct operation of system applications, and serves as 

25 common language among applications, the application manager 16 and the hardware 

26 resource manager 18 for specifying required and available resources during system 

27 resource allocation. 

28 The cited Osborn portion column 4 lines 15-23 reads as stated above. 

29 These fail to support the alleged teaching. 
30 

31 16. As for claim 11, Osborn discloses each and every limitation of claim 10. Osborn 

32 further discloses wherein the best practices are encoded as patterns in a best practices 
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1 catalog and used in the step & forming said Concrete Model ( Osborn discloses the 

2 requirements are derived from an application object library column 3 lines 9-12). 



3 The cited Osborn portion column 3 lines, 9-12 fails to support the above. It reads: 

4 The application manager 16 retrieves software objects 36 required to run the application 

5 from an application object library 37 (FIG. 2) based on the virtual objects 35, and loads 

6 the objects 36 onto the hardware processors 20, 22, 24 through a mapping function 

7 represented generally at 38 based on hardware resource allocation information provided 

8 by the hardware resource manager 18 and facilitated by the hardware resource identifier 

9 19. 
10 

11 17. As for claims 12 and 22, Osborn discloses each and every limitation of claims 1 and 

12 21. 

13 Osborn further discloses (means for) employing said Concrete Model to generate 

14 provisioning actions said provisioning actions, when executed, create a resource 

15 structure that matches the description in the Concrete Model, said, resource structure 

16 satisfies said set of requirements on new desired state of said service environment 

17 ( Osborn discloses obtaining an abstract resource description describing virtual 

18 hardware resource objects and using the abstract resource description to create a 

19 matching resource structure to satisfy the requirements of the service environment, see 

20 column 3 lines 60-67). 
21 

22 18. As for claim 13, Osborn discloses each and every limitation of claim 12. Osborn 

23 further discloses employing said provisioning to enforce policy based service provider's 

24 best practices in implementation of service environments in the computing utility 

25 infrastructure (Osborn discloses employing provisioning to enforce the requirements 

26 needed to run the application, see column 3 lines 1-8, 60-67 and column 4 lines 15-23). 

27 19. As for claim 14, Osborn discloses each and every limitation of claim 13. Osborn 

28 further discloses wherein the best practices are encoded as patterns in a best practices 

29 catalog and used in the step of forming the Concrete Model ( Osborn discloses the 

30 requirements are derived from an application object library column 3 line 9-12). 
31 

32 20. As for claims 19 and 24, Osborn discloses each and every limitation of claims I and 

33 21. 

34 Osborn further discloses (means for) employing said Concrete Model to generate a 

35 Resource Manager for a composite resource (Osborn discloses that a hardware resource 

36 manager employs the application hardware resource specification and a hardware 

37 resource diagram, which represents a composite resource, see column 6 lines 3-20 and 
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1 Figure 8, to allocate the composite resource and thereby create a resource manager for 

2 the composite resource, see column 7 lines 1-25). 

3 The cited O shorn portion column 7 lines 1-25 fails to support the above. It reads: 

4 Subsequent to generating the hardware resource diagram, the hardware resource 

5 specification 40, an application hardware resource specification 72 that is, for example, 

6 an ASCII file, is generated to describe the hardware resources required by an application. 

7 The manner in which the hardware resource specification is generated is similar to the 

8 above-described manner in which the abstract resource diagram is generated, except that 

9 not all attributes and resources assigned to the hardware resources need to be specified. 

10 FIG. 9 is an exemplary hardware resource specification generated in response to an 

1 1 application requiring the power PC processor 154a' as the PCI bus host, and an RF 

12 resource group including two serial RS422 ports 154b', 154c' associated with the receiver 

13 and the transmitter, two Altera 250 FPGAs 146c', 146d', and one Share processor 146a'. 

14 Further, the hardware specification 72 also dictates via the virtual RF resource group 189 

15 that the application requires all resources except for the power PC to come from the same 

16 RF resource group. The hardware resource manager 18 then parses the definitions and 

17 constraints in the application hardware resource specification 72 and matches the 

18 resources required by the application with the best available resources. For example, if 

19 the resources shown in FIG. 10 represent all available hardware resources, the hardware 

20 resource manager 18 would allocate the available resources in the RF resource group 146 

21 as well as the power PC processor 154a having sufficient connectivity, represented by the 

22 darkened boxes, to the application. 

23 21. As for claim 23, Osborn discloses each and every limitation of claim 21. Osborn 

24 further discloses a computer program product comprising a computer usable medium 

25 having computer readable program code means embodied therein for causing generation 

26 a Concrete Model, the computer readable program code means in said computer 

27 program product comprising readable program code means for causing a computer to 

28 effect the functions of claim 21 ( Osborn discloses the system of Figures 1 and 2 to effect 

29 the functions of claim 21, see Figures 1 and 2). 
30 
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1 22. As for claim 25, O shorn discloses each and every limitation of claim 1. O shorn 

2 further discloses where the step of generating a Concrete Model is performed by a user 

3 taken from a group of users consisting of: 
4 

5 a. service provider, 
6 

7 a customer of a service provider, 
8 

9 a company owning an IT infrastructure (Osborn discloses an application developer, see 

10 column 3 lines 1-15 and column 8 lines 12-23), and 
11 

12 a utility provider (Osborn discloses an application developer,, see column 3 lines 1-15 

13 and 
14 

15 column 8 lines 12-23). 

16 The cited Osborn portion column 3 lines 1-15 reads as stated above. 

17 The cited Osborn portion column 8 lines 12-23 reads: 

18 Also, the present invention is applicable to highly complex super-communication circuits 

19 in which multiple channels of hardware resources are allocated to a single application 

20 performing higher level sub-channel, or, in other words, multiplexed communications 

21 path, management. Specifically, the hardware resource manager enables an application 

22 developer, through use of the resource group concept, to assign sub-channel objects to the 

23 same resource group within a larger application. Examples of such super-communication 

24 circuits include bridging and simulcast/receive communications topologies. 



25 In response, the applicants respectfully states that as stated above, exception is taken with the 

26 alleged teaching of the elements of Claims 1-6, 9-14, 19, and 21-25 by Osborn. The argument 

27 given for method claim 1, is similarly applicable to the apparatus claims. A review of all the 

28 cited portions of Osborn fails to support the teaching of any of the claims 1-25 of this 

29 application. The cited portions are copied below to show that indeed the alleged teaching of the 

30 elements of each claim are apparently not in Osborn. 



DOCKET NUMBER: CH920010003US1 



29/44 



Serial No.: 10/776,297 



1 Thus, all claims are not taught and are allowable over Osborn, even when combined with the 

2 other references cited below, for obviousness purposes. 

3 Claim Rejections -35 USC § 103 

4 

5 23. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

6 obviousness rejections set forth in this Office action: 
7 

8 (a) A patent may not be obtained though the invention is not identically disclosed or 

9 described as set forth in section 102 of this title, if the differences between the subject 

10 matter sought to be patented and the prior art are such that the subject matter as a whole 

1 1 would have been obvious at the time the invention was made to a person having ordinary 

12 skill in the art to which said subject matter pertains. Patentabilty shall not be negatived 

13 by the manner in which the invention was made. 
14 

15 

16 24. Claims 7 and 8 are rejected under 35 U.S.C. 103(a) as being unpatentable over 

17 Osborn, as applied to claim 1 above, and in further view of U.S. Patent Application 

1 8 Publication No. US 2003/0208473 Al filed on January 28, 2000 by Lennon (denoted 

19 herein as "Lennon"). 

20 The further cited art to Lennon , US Patent Pub 2003/0208473, filed: January 28, 2000, is 

21 entitled: "Browsing electronically-accessible resources". 

22 The abstract reads: 

23 "A method of browsing electronically- accessible resources using descriptions of the 

24 resources. These descriptions have descriptor components, which have attributes 

25 representative of at least two axes of access to the resources. These descriptions also have 

26 links to the corresponding resources. The method first reads the descriptions and displays 

27 a number of items (1608). Each one of these items are associated with a corresponding 

28 descriptor component of the read description that has an attribute. The method allows the 

29 browsing (1602,1603) of the descriptions and their corresponding 

30 electronically- accessible resources via the links using the displayed items". 

31 So, there is no reason to make this combination except in an attempt to find a combination that 

32 allegedly has the elements of these claims to make the claims obvious. This is hindsight which is 

33 not allowed. But, even the combination does not teach the combined elements. 
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1 25. As for claim 7, O shorn discloses each and every limitation of claim 1. O shorn does 

2 not explicitly disclose, but Lennon discloses wherein the step of Forming a Concrete 

3 Model includes: 
4 

5 at least one refinement step comprised of selecting a node and replacing said, node with 

6 a sub graph structure to obtain an intermediary model which is an input to a next 
1 refinement step (Lennon discloses selecting the description object in a resource 

8 description, see DDF on page 9 paragraphs 115 and 116, and replacing it with a sub tree 

9 structure, sec Figure 5, to produce a description object model, see page 11 paragraphs 

10 154-156 and Figures 2A and 2B); repeating the step of selecting and replacing until a 

1 1 resulting intermediary model is mappable to said knowledge subsystem (Lennon discloses 

12 the description object model, or DesOM, represents resources and resource relationships 

13 mappable to the system, see page I paragraphs 154-156 and Figures 2 A and 2B). 
14 

15 It would have been obvious to one of ordinary skill in the art at the time of the invention 

16 to modify Osborn's disclosure of forming a Concrete Model and of a description of 

17 resources (Service Environment Model) to include refining the description of resources to 

18 produce a Concrete Model in order to provide a consistent method of describing 

19 resources and thereby utilizing resource descriptions, see page 1 paragraph 6 of Lennon. 

20 The cited Lennon portions copied below fail to support the alleged teaching. Page 9 paragraphs 

21 115 reads: 

22 [0115] The preferred DDE attempts to incorporate the benefits of declarative description 

23 of content with procedural methods for the creation and processing of descriptors. It 

24 comprises an object model, an API for the processing of descriptions, and a serialisation 

25 syntax. The DDF can be used to adequately describe content using these components. 

26 The cited Lennon portion page 9 paragraphs 116 reads: 

27 [0116] The object model provides the core semantics of the description and is based on 

28 the descriptor entity. This model has the advantage that the containment relationship is 

29 inherent in the model. This containment relationship is particularly important in the 

30 description of audiovisual resources for two reasons. First, the structure of many 

31 audiovisual resources has an inherent hierarchical structure (eg., a video clip contains 

32 shots which contain key frames, etc.). Second, the representation values for many 

33 descriptors can be complex datatypes that can be represented in a hierarchical fashion 

34 (eg., a histogram contains bins which contain frequencies). The object model of the 
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1 preferred DDF is called the Description Object Model DesOM). It is discussed in Section 

2 2.2. 

3 The cited Lennon portion page 1 paragraph 6 reads: 

4 [0006] If a consistent method of describing resources can be achieved then consistent 

5 methods of selecting resource descriptions from formulated queries can be contemplated 
6 

7 26. As for claim 8, O shorn and Lennon in combination disclose each and every 

8 limitation of claim 7. Lennon further discloses wherein said step of replacing comprises a 

9 limitation taken from a group of limitations consisting of querying a best practices 
10 catalog; generating sub graph patterns dynamically; 

11 

12 employing graph matching techniques to obtain said sub-graph structure (Lennon 

13 discloses matching the sub tree structure to the description object, see page 11 

14 paragraph 155 and Figure 5); 
15 

16 employing graph merging techniques to obtain said sub-graph structure (Lennon 

17 discloses merging the sub tree structure to the description object, see page 11 paragraph 

18 155 and Figure 5); any combination of these limitations. 

19 

20 It would have been obvious to one of ordinary skill in the art at the time of the invention 

21 to modify Osborn's disclosure of forming a Concrete Model and of a description of 

22 resources (Service Environment Model) to include refining the description of resources to 

23 produce a Concrete Model in order to provide a consistent method of describing 

24 resources and thereby utilizing resource descriptions, see page 1 paragraph 6 of Lennon. 

25 The cited Lennon portion page 11 paragraph 155 reads: 

26 [0155] For a description to conform to the preferred DDF, the root of the DesOM must be 

27 a Description object. In other words, the root must specify the resource to which the 

28 description refers. Since a Description object is just a specialisation of the Descriptor 

29 object, any Description object can become a sub-tree of another Description object. In 

30 other words, a new Description object can be created from a set of related Description 

31 objects. This process is shown in FIG. 5. 

32 employing graph merging techniques to obtain said sub-graph structure (Lennon 

33 discloses merging the sub tree structure to the description object, see page 11 paragraph 

34 155 and Figure 5 ); 



DOCKET NUMBER: CH920010003US1 



32/44 



Serial No.: 10/776,297 



1 The cited Lennon portion page 1 1 paragraph 155 reads as stated above. 

2 any combination of these limitations. It would have been obvious to one of ordinary skill 

3 in the art at the time of the invention to modify Osbom's disclosure of forming a Concrete 

4 Model and of a description of resources (Service Environment Model) to include refining 

5 the description of resources to produce a Concrete Model in order to provide a consistent 

6 method of describing resources and thereby utilizing resource descriptions, see page 1 
1 paragraph 6 of Lennon. 

8 

9 27. Claims 15 and 16 are rejected under 35 U.S.C. 103(a) as being unpatentable over 

10 Osborn, as applied to claim 12 above, and in further view of U.S. Patent No. 6,332,023 

11 BI issued on December 18, 2001 to Porter et al. (denoted herein as "Porter"). 

12 The further cited art to Porter , US Patent Pub 6,332,023, filed: June 4, 1998, is entitled: 

13 "Method of and system for providing services in a communications network". 

14 The abstract reads: 

15 "A system for providing services in a communications network includes a service 

16 processing function, a universal directory function, and a nodal resource manager. The 

17 service processing function receives service requests, formulates requests for 

18 interworking functions based upon service requests, and formulates resource requests 

19 based upon service requests and interworking functions. The universal directory function 

20 receives addresses from the service processing function and returns interworking 

21 functions based upon addresses. The nodal resource manager receives resource requests 

22 and allocates resources to the service processing function in response to resource 

23 requests. The nodal resource manager maintains a resource database that includes an entry 

24 corresponding to each network resource managed by the nodal resource manager". 

25 This also fails to support the alleged teaching. 

26 28. As for claim 15, Osborn discloses each and every limitation of claim 12. In addition, 

27 Osborn and Porter in combination disclose wherein step of provisioning includes a task 

28 taken from a group of tasks consisting of: 
29 

30 creating a new service environment ( Osborn discloses allocating resources to an 

31 application to create a service environment, see column 3 lines 60-67), changing the 
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1 combination of resources allocated to a service environment ( O shorn discloses allocating 

2 resources to an application to create a service environment, see column 3 lines 60-67. 

3 In addition, Porter discloses dc-allocating resources allocated to a service environment, 

4 see column 3 lines 40-50), changing the configuration of resources allocated to a service 

5 environment (Porter discloses changing the configuring of a resource that has been 

6 allocated to a service environment, see column 3 lines 30-40), or destroying a service 
1 environment, or any combination of the above. 

8 

9 It would have been obvious to one of ordinary skill in the art at the time of the invention 

10 to modify Osborn's disclosure of provisioning to include the ability to change the 

1 1 configuration of resources in order to provide for a more flexible allocation of resources, 

12 See column 2 lines 35-54 of Porter. 

13 In response, the applicants respectfully states that the cited Porter portions fail to support the 

14 alleged teaching. Column 3 lines 60-67 reads: 

15 Every resource manager has a domain, which is the set of resources managed by the 

16 resource manager. The domain of a nodal resource manager is the set of resources 

17 available to a network node, as the network is currently configured. The system of the 

18 present invention may include a network resource manager, whose domain is all 

19 connective resources of the network. The network resource manager can reconfigure the 

20 network and allocate additional network resources to a nodal resource manager. In the 

21 event a nodal resource manager cannot satisfy a resource request, the nodal resource 

22 manager may request additional resources from the network resource manager. 

23 BRIEF DESCRIPTION OF THE DRAWINGS 

24 FIG. 1 is a block diagram of a communications network according to the present 

25 invention. 

26 FIG. 2 is a block diagram of a network node according to the present invention. 
27 

28 In addition, Porter discloses de-allocating resources allocated to a service environment, 

29 see column 3 lines 40-50), 

30 The cited Porter portion column 3 lines 40-50 reads: 
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1 Preferably, the evaluation function ranks unallocated candidate resources higher than 

2 allocated candidate resources. However, occasionally the best candidate may already be 

3 allocated to a lower priority service processing function. In those situations, the resource 

4 manager de-allocates the best candidate resource and notifies the earlier service 

5 processing function that its use of the resource has been preempted. Then the resource 

6 manager reconfigures the resource and allocates the resource to the higher priority service 

7 processing function. 

8 changing the configuration of resources all Ocated to a service environment (Porter 

9 discloses changing the configuring of a resource that has been allocated to a service 

10 environment, see column 3 lines 30-40), or destroying a service environment, or any 

1 1 combination of the above. It would have been obvious to one of ordinary skill in the art at 

12 the time of the invention to modify Osbom's disclosure of provisioning to include the 

13 ability to change the configuration of resources in order to provide for a more flexible 

14 allocation of resources, see column 2 lines 35-54 of Porter. 

15 The cited Porter portion column 2 lines 35-54 reads: 

16 The approach of the '075 patent cannot optimize the path subject to instantaneous changes 

17 in the network or based upon per-resource cost metrics. More generally, the '075 patent 

18 continues to confound service and addressing functions within a single database. As in 

19 traditional telephony, there is no recognition of the need to segregate service logic and 

20 addressing data. Furthermore, the approach of the '075 patent cannot effectively serve 

21 new types of traffic or services that may require flexible allocation of intervening 

22 resources, such as store-and-forward devices. 

23 There is a need for a flexible routing technique in a telecommunications network that 

24 encompasses more than a fixed mapping of numbers to trunk groups, or a fixed mapping 

25 of origination information to network resources. A new routing technique is required that 

26 takes into account many factors in routing a call and it can be applied in a multi-purpose 

27 communications network, rather than just for telephony. 

28 
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1 29. As for claim 16, Osborm and Porter in combination disclose each and every 

2 limitation of claim 15. Porter further discloses wherein changing the configuration of 

3 resources allocated to a service environment include: 
4 

5 changing the local state of a resource (Porter discloses updating static and dynamic 

6 resource attributes, see column 1 lines 66-67, column 3 lines 1-20). or 
1 

8 changing the wax the resource is configured to work with other resources. 
9 

10 It would have been obvious to one ofordinaiy skill in the art at the time of the invention 

11 to modify Osborn's disclosure of provisioning to include the ability to change the 

12 configuration of resources in order to provide for a more flexible allocation of resources, 

13 see column 2 lin es 35-54 of Porter. 

14 In response, the applicants respectfully states that the cited Porter portion column I lines 66-67 

15 reads: 

16 Although the traditional routing table approach has sufficed for traditional telephone use 

17 under normal conditions, it has become inadequate to accommodate new types of services 

18 and traffic. 

19 The cited Porter portion column 3 lines 1-20 reads: 

20 The present invention provides a method of and a system for providing services in a 

21 communications network. The system includes a service processing function, a universal 

22 directory function, and a resource manager. The service processing function receives 

23 service requests, formulates requests for interworking functions based upon service 

24 requests, and formulates resource requests based upon service requests and interworking 

25 functions. The universal directory function receives logical addresses from the service 

26 processing function and returns interworking functions based upon addresses. The 

27 resource manager receives resource requests and allocates resources to the service 

28 processing function in response to resource requests. The resource manager accesses and 

29 updates a resource database that includes an entry corresponding to each network 

30 resource managed by the resource manager. 

31 Each entry of the resource database includes a resource identifier, a set of static attributes, 

32 and a set of dynamic attributes. A resource identifier uniquely identifies a resource. Static 

33 attributes are relatively stable data about the type and configuration of the resource. 
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1 Dynamic attributes are changing data about the resource that are tracked by the resource 

2 manager, including such data as whether the resource is being used, and if so, by whom. 

3 If a resource is allocated, the dynamic attribute of the resources will include an indicator 

4 on how to find the priority of the allocation. This is because the priority of an allocation 

5 could be dynamic, i.e., the function owning a resource may assign varying priority during 

6 the duration of the allocation, or static, i.e., the priority is determined at allocation time 

7 and is fixed, so that it can be stored in the resource. 

8 The cited Porter portion column 2 lines 35-54 reads as stated above. 

9 This fails to teach the claimed element. 
10 

11 30. Claims 17 and 18 are rejected under 35 U.S.C. 103(a) as being unpatentable over 

12 Osborn, as applied, to claim 1 above, and in further view of U.S. Patent Application 

13 Publication No. US 2004/0128397 Al filed on September 10, 2003 by Glasmann et al 

14 ( denoted herein as "Glasmann "). 

15 Whereas, the cited art to Glasmann, US Patent Pub 2004/0128397, filed: September 10, 2003, is 

16 entitled: "Method for checking transmission resources of a packet-oriented communication 

17 network when there are topology changes," abstract reads: 

18 "To check transmission resources of a packet-oriented communication network on a 

19 topology change, a resource manager checks a reservation of the transmission resources 

20 based on the topology data relating to the topology of the communication network. Upon 

21 a topology change of the communication network, topology change information is 

22 transferred to the resource manager. The resource manager records new topology data 

23 which relates to the changed topology of the communication network. Based on the new 

24 topology data, the resource manager maps an existing reservation of the transmission 

25 resources to the changed topology of the communication network". 

26 There is no reason to make this combination by one skilled in the art except using hindsight, not 

27 allowed in a 103 rejection 

28 31. As for claim 17, Osborn discloses each and every limitation of claim 1. Osborn does 

29 not explicitly disclose, but Glasmann discloses regenerate provisioning instructions 

30 whenever at least one of the following occurs: 
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1 

2 infrastructure characteristics change ( Glasmann discloses allocating resource 's when 

3 there is a change in the topology, see page 1 paragraph 5, 8, and 9), and 
4 

5 requirements of a service change. 
6 

7 It would have been obvious to one of ordinary skill in the art at the time of the invention 

8 to modify Osborn's disclosure of provisioning resources to include providing resources 

9 when infrastructure characteristics change in Order to provide for adaptive resource 

10 checking and reacting to topology changes (see page 1 paragraphs 7 and 10 of 

11 Glasmann). 

12 In response, the applicants respectfully states that The cited Glasmann portion page 1 paragraph 

13 5, 8, and 9 reads: 

14 [0005] In practical operation of a communication network this topology can occasionally 

15 change. Such a topology change can for example be caused by an administrative 

16 configuration change or by a failure or a recovery of a network component. As a result 

17 can there can be a dynamic change of communication routes in the communication 

18 network on Layer 2 (e.g., through so-called spanning-tree procedures) and/or Layer 3 

19 (e.g., by routing procedures such as RIP or OSPF) of the OSI reference model. 

20 [0008] To check transmission resources of a packet-oriented communication networks on 

21 topology changes a resource manager is provides which checks an reservation of the 

22 transmission resources in particular by connections, on the basis of the topology data 

23 relating to the topology of the communication network. A topology change in this 

24 document is also taken to mean changes to a network configuration or changes to 

25 operating conditions of the communication network. In accordance with the invention, as 

26 a result of a change to the topology of the communication network topology change 

27 information is sent to the resource manager. As a result the resource manager is caused to 

28 create new topology data relating to the changed topology of the communication network. 

29 On the basis of the new topology data created the resource manager maps an existing 

30 reservation of the transmission resources to the changed topology of the communication 

31 network. 
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1 [0009] A significant advantage of the invention lies in the fact that the resource manager 

2 can detect at an early stage and react to topology changes which as a rule result in a 

3 temporary inconsistency of a topology image present in the resource manager with the 

4 current topology of the communication network. By mapping the existing reservation of 

5 resources to the changed topology resource guarantees can be maintained for the 

6 connections which existed before the topology change, provided that can be combined 

7 with the new topology. In addition the transmission resources available after the change 

8 can be used particularly efficiently. 

9 This does not support the teaching alleged above. 
10 

11 32. As for claim 18, Osbom and Glasmann in combination disclose each and every 

12 limitation of claim 17. Glasmann further discloses wherein the infrastructure 

13 characteristics include a characteristic taken from a group of characteristics consisting 

14 of: 
15 

16 types of resources in the infrastructure, capabilities of said resources (Glasmann 

17 discloses topology changes include changes in the capabilities of a resource, see page 1 

18 paragraphs 4 and 5), configuration of said resources ( Glasmann discloses topology 

19 changes include changes in the configuration of a resource, see page 1 paragraphs 4 and 

20 5), constraints on configuration of said resources, best practices ' patterns as defined in 

21 the best practices catalog. 

22 and any combination of the above. 

23 It would have been obvious to one of ordinary skill in the art at the time of the invention 

24 to modify Osborn's disclosure of provisioning resources to include providing resources 

25 when infrastructure characteristics change in order to provide for adaptive resource 

26 checking and reacting to topology changes (see page 1 paragraphs 7 and 10 of 
21 Glasmann). 

28 The cited Glasmann portion page 1 paragraphs 4 and 5 reads: 

29 [0004] To be able to establish whether transmission resources requested for a connection 

30 are available on the primary route of this connection through the communication network 

31 the resource manager needs information about the topology of the communication 

32 network, i.e. about the networking structure of the network nodes and link lines and about 

33 their relevant transmission capacity. This type of topology information which specifies 

34 the topology of a communication network is frequently referred to as a topology image. 
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1 [0005] In practical operation of a communication network this topology can occasionally 

2 change. Such a topology change can for example be caused by an administrative 

3 configuration change or by a failure or a recovery of a network component. As a result 

4 can there can be a dynamic change of communication routes in the communication 

5 network on Layer 2 (e.g., through so-called spanning-tree procedures) and/or Layer 3 

6 (e.g., by routing procedures such as RIP or OSPF) of the OSI reference model. 

7 configuration of said resources ( Glasmann discloses topology changes include changes 

8 in the configuration of a resource, see page 1 paragraphs 4 and 5), 

9 constrain ts on configuration of said resources, best practices patterns as defined in the 

10 best practices catalog, and any combination of the above. It would have been obvious to 

1 1 one of ordinary skill in the art at the time of the invention to modify Osbom 's disclosure 

12 of provisioning resources to include providing resources when infrastructure 

13 characteristics change in order to provide for adaptive resource checking and reacting to 

14 topology changes (see page 1 paragraphs 7 and 10 of Glasmann). 

15 The cited Glasmann portion page 1 paragraphs 4 and 5 reads as stated above. 

16 The cited Glasmann portion page 1 paragraphs 7 and 10 reads: 

17 [0007] An object of this invention is to specify a method of checking transmission 

18 resources of a packet-oriented communication network which allows adaptive resource 

19 checking when the topology of the communication network changes. 

20 [0010] Advantageously the resource manager can temporarily change over to a static 

21 resource reservation mode as a result of receiving the topology change information. In the 

22 static resource reservation mode the transmission resources are reserved preferably in 

23 accordance with a method independent of the reservation of the transmission resources or 

24 of dynamic changes to the topology image or the topology data. 

25 Support is not shown here either. 

26 33. Claim 20 is rejected under 35 U.S.C. 103(a) as being unpatentable over Osbom. as 
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1 

2 applied to claim 19 above, and in further view of U.S. Patent No. 6,901,446 B2 filed on 

3 February 28, 2001 by Chellis et al. (denoted herein as "Chellis"). 

4 Whereas, the cited art to Chellis, US Patent 6,901,446, filed: February 28, 2001, is entitled: 

5 "System and method for describing and automatically managing resources," abstract reads: 

6 "A system and method for automatically allocating resources is provided. The system 

7 includes one or more components for automatically allocating one or more resources, 

8 based at least in part on data associated with the one or more resources, the data including 

9 at least one of, type data, instance data, characteristic data, and dynamically modifiable 

10 metadata. An alternative aspect of the system provides one or more components for 

1 1 automatically allocating one or more resources distributed on a plurality of resource 

12 allocation servers. The one or more components for automatically allocating the one or 

13 more resources can improve utilization of the capacity of the one or more resources. In an 

14 alternative embodiment the system includes an Application Programming Interface (API) 

15 operable to configure and/or control the one or more components for automatically 

16 allocating one or more resources". 

17 34. As for claim 20, Osborn discloses each and every limitation of claim 19. Osborn does 

18 not explicitly disclose, but Chellis discloses wherein said Resource Manager provides a 

19 set of resource manager methods taken from a group of resource manager methods 

20 consisting of: 
21 

22 creating composite resources based on a Concrete Model (As mentioned above, Osborn 

23 does disclose a resource manager for a composite resource. However, Osborn does not 

24 explicitly disclose, but Chellis discloses a resource manager capable of creating a 

25 composite resource, or set of interdependent resources, based on defined resource 

26 requirements for a service, see column 3 lines 36-59), changing composite resources 

27 based on a Concrete Model (As mentioned above, Osborn does disclose a resource 

28 manager for a composite resource. However, Osborn does not explicitly disclose, but 

29 Chellis discloses a resource manager capable of changing a composite resource, or set of 

30 interdependent resources, based on defined resource requirements for a service, see 

31 column 3 lines 36-67 column 4 lines 1-27 and column 9 lines 55-67). 

32 destroying composite resources based on a Concrete Model, and any combination of 

33 these methods. 
34 

35 It would have been obvious to one of ordinary skill in the art at the time of the invention 

36 to include in Osborn' s disclosure of a resource manager the ability to create and change 
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1 composite resources in order to provide increased functionality to the resource manager 

2 and, in addition, to provide for more robust allocation of composite resources (see 

3 column 2 lines 44-67 and column 3 lines 1-6). 

4 The cited Chellis portion column 3 lines 36-67 reads: 

5 The present invention includes initially defining resource requirements for a service. The 

6 operation of the present invention includes the ability to redefine resource requirements, 

7 allocation rules and algorithms to more efficiently utilize resources available to be 

8 allocated. The resources to be allocated can change in numbers, characteristics and types. 

9 Further, the mix of resources required for an application and/or service can change. Thus, 

10 the present invention provides a system and method for defining resources, for 

1 1 manipulating the pool of resources available (e.g., adding/subtracting resources 

12 dynamically based on usage), for tracking the resources available and for defining and 

13 managing dependency relationships between applications, sessions and/or resources. By 

14 way of illustration, a new resource type can be created, with the creation including 

15 recording information concerning the new resource type (e.g., disk capacity, disk speed, 

16 number of concurrent users). Similarly, an existing resource can have its characteristics 

17 change (e.g., bandwidth increased/decreased, disk size increased/decreased). By way of 

18 further illustration, instances of a type can be added to the pool of resources available for 

19 allocation, and once added to the pool, the status (e.g., availability, online/offline, 

20 allocated/not-allocated) of the resource can be tracked. 

21 Dependencies can exist between items including, but not limited to, services and 

22 resources. For example, a first consumer access to a first service may require allocating a 

23 first resource and a second resource, while a second consumer access to a second service 

24 may require allocating a first resource, a second resource and two instances of a third 

25 resource. Further, there may be dependencies between resources. For example, to allocate 

26 a first resource may require that a second resource and a third resource be available to be 

27 allocated. For example, a router resource may require that a data communication channel 

28 resource and a data security resource be available before the first resource can be 

29 allocated. In the present invention, a resource may be defined so that a service is a 
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1 resource to another service. For example, a database lookup service may be a resource 

2 required by an email service and a chat room service. 

3 The cited Chellis portion column 4 lines 1-27 reads: 

4 Dependencies can exist between items including, but not limited to, services and 

5 resources. For example, a first consumer access to a first service may require allocating a 

6 first resource and a second resource, while a second consumer access to a second service 

7 may require allocating a first resource, a second resource and two instances of a third 

8 resource. Further, there may be dependencies between resources. For example, to allocate 

9 a first resource may require that a second resource and a third resource be available to be 

10 allocated. For example, a router resource may require that a data communication channel 

1 1 resource and a data security resource be available before the first resource can be 

12 allocated. In the present invention, a resource may be defined so that a service is a 

13 resource to another service. For example, a database lookup service may be a resource 

14 required by an email service and a chat room service. 

15 The data concerning resources can include data (in the form of properties and/or attributes 

16 about the resource and metadata (data about data)). The data concerning a resource can 

17 include type and relationship data. For example, a resource can be generally characterized 

18 by data including, but not limited to, its name, capacity in units relevant to the resource 

19 (e.g. megabytes, CPU cycles or transactions per second), operating characteristics, 

20 relationships with other resources, and dependencies on other resources. An instance of a 

21 resource may be more particularly characterized by data including, but not limited to, its 

22 allocation status, its availability, and its current allocation to services and/or resources. 

23 The metadata concerning a resource can include data about how to define a resource. For 

24 example, a resource definition may require registering N fields, (N being an integer), 

25 where a first field requires a string of M characters, (M being an integer), the characters 

26 corresponding to a resource name, where the second field requires a thirty-two bit 

27 globally unique identifier (GUID), and so on. 

28 and column 9 lines 55-67), 
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1 destroying composite resources based on a Concrete Model, and any combination of 

2 these methods. It would have been obvious to one of ordinary skill in the art at the time of 

3 the invention to include in Osbom's disclosure of a resource manager the ability to create 

4 and change composite resources in order to provide increased functionality to the 

5 resource manager and, in addition, to provide for more robust allocation of composite 

6 resources (see column 2 lines 44-67 and column 3 lines 1-6). 

7 In response, the applicants respectfully states that the various combinations of art fail to make 

8 any of the claims obvious, since they all are combined with Osborn which fails to teach even the 

9 independent claims. 

10 Claims have been further amended to bring this to quick allowance. It is anticipated that this 

11 brings claims 1-25 as amended to allowance. 

12 Please charge any fee necessary to enter this paper to deposit account 50-0510. 

13 Respectfully submitted, 

14 By: /Louis Herzberg/ 

15 Dr. Louis P. Herzberg 

16 Reg. No. 41,500 

17 Voice Tel. (845) 352-3194 

18 Fax. (845) 352-3194 

19 3 Cloverdale Lane 

20 Monsey, NY 10952 

21 Customer Number: 54856 
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